In internet protocol (IP) based networks, each device on the network which is to communicate with another device must have a unique IP address. This requirement potentially places limits on the growth of IP networks since the supply of new, unused IP addresses is now becoming a scarce resource as a result of the phenomenal growth in use of IP based networks.
A typical and widely used solution to this problem is to isolate IP networks from public networks and to use a private IP numbering scheme within the network which may be replicated in many private networks around the world thus allowing the reuse of the private numbers. In order to allow such networks to communicate with other private networks across public networks, it is necessary to use a technique such as network address translation in which private IP addresses are mapped to public IP addresses so that IP packets can traverse public networks. Typically a small number of public IP addresses are used and mapping occurs between ports on private IP addresses within the private network and ports on the small number of public IP addresses used at the edges of the private network. Thus by reducing the requirements for public IP addresses, the problem of scarcity of IP addresses is significantly mitigated.
This type of technique has also found widespread application in the use of virtual private networks (VPNs) in which data is tunnelled over public networks in an encrypted tunnel. This usually involves some form of network address translation in the sense that the IP address and ports used for the packets forming the encrypted tunnel will not relate to the packets and ports contained within the tunnel other than by way of mappings within a NAT device.
However, many of the more complex protocols typically used for transmitting data such as voice over IP, video over IP, instant messaging and so on cannot traverse simple NAT devices since call set up and maintenance for these protocols requires significant “intelligence” in the receiving and transmission device. In the case of a path traversing a NAT device, the transmitting device cannot see the ultimate receiving device (which is replaced by the NAT at the external edge of the private network). One solution to this problem is to provide the NAT with the same intelligence (in relation to the relevant protocol) as the ultimate receiving device. The NAT must also be able to emulate the transmitting device so that the receiving device is able to interact with the relevant protocol correctly. Another solution is to add a device into the data path that is ‘aware’ of and can operate correctly through NATs. Such a device is typically called a ‘media proxy’. This problem is described in detail in co-pending, co-assigned U.S. application Ser. No. 10/447,908 of 28 May 2003.
It will be appreciated that a media proxy is complex and therefore expensive. Accordingly media proxies are usually a relatively scarce resource within a network since they are too expensive to scatter liberally throughout a network on the off-chance that they will be used.
As described in more detail below, a call agent within the network will typically set up a path between two media endpoints which will include media streams.
Although the selection of an appropriate media proxy at first sight sounds reasonably straightforward, a more detailed analysis shows that selection of an optimal media proxy is a complex problem.
Firstly, the geographical location and input and output bandwidth of the media proxy must be considered. For example, there is little value in selecting a media proxy based in North America for a media stream between media endpoints which are based entirely in Europe since this would cause the traffic to be carried across the Atlantic in both directions on what would typically need to be high quality links (to ensure adequate bandwidth and latency performance). On the other hand, there is also little value in provisioning a media proxy local to both media endpoints if for some reason it is a particularly expensive media proxy to use, for example.
Secondly, there is presently no clearly defined arrangement for choosing a second best media proxy if the first proxy is unsuitable (for example because it is already being used to capacity and is therefore unavailable).
Thirdly, there is presently no mechanism for ensuring that paths between media endpoints belonging to the same enterprise (for example paths between two private networks at different office locations) use a media proxy which is local to the enterprise. This may mean that high charges are being incurred with a service provider to use a media proxy even though a local proxy within the enterprise's own network is available.
Thus with no provisioning model whatsoever, the problems outlined above occur frequently. Accordingly, attempts have been made to provide provisioning models to ensure that call agents use sensible choices of media proxies.
One solution is to provide a large number of media proxies at known locations so that it can be assumed that any particular media endpoint for example in a particular country may use a media proxy based in that country. However, this has a large provisioning cost (since there will be a large number of media proxies) and furthermore if there is no direct match with the location for a particular media endpoint and a media proxy, there is no fall back method for selecting a second best or next nearest media proxy resource.
Another approach is to use an auto discovery technique. Theoretically, this should be the ideal solution and would be achieved by having the source media endpoint test the network to determine the most suitable (typically the quickest) link to the destination endpoint. However, in practice, this requires a broadcast from a media endpoint to all media proxies with a time measurement. This uses network resources and requires the media endpoint to be relatively “intelligent”. Furthermore, the broadcast signal is unlikely to put the same bandwidth stresses on the path which is being tested as the data ultimately will. Thus the path chosen using auto-discovery may fail or not perform as well as expected when real data is passed over it. This potential solution, is therefore presently impractical.